\documentclass[12pt]{article}

   \usepackage[pdftex]{graphicx}

\pagestyle{empty}
\setcounter{secnumdepth}{2}

\topmargin=0cm
\oddsidemargin=0cm
\textheight=22.0cm
\textwidth=16cm
\parindent=0cm
\parskip=0.15cm
\topskip=0truecm
\raggedbottom
\abovedisplayskip=3mm
\belowdisplayskip=3mm
\abovedisplayshortskip=0mm
\belowdisplayshortskip=2mm
\normalbaselineskip=12pt
\normalbaselines

\begin{document}

\vspace*{0.5in}
\centerline{\bf\Large Design Document}

\vspace*{0.5in}
\centerline{\bf\Large Team 6}

\vspace*{0.5in}
\centerline{\bf\Large March 11, 2012}

\vspace*{1.5in}
\begin{table}[htbp]
\caption{Team}
\begin{center}
\begin{tabular}{|r | c|}
\hline
Name & ID Number \\
\hline\hline
Joseph Klimos & 9192158 \\
\hline
Yu-Shang Lin & Y \\
\hline
Han Bin Rong & Y \\
\hline
Jordan Victor & Y \\
\hline
David Bergamin & Y \\
\hline
Alec Chamberland & Y \\
\hline
Rodrigue Fares & Y \\
\hline
\end{tabular}
\end{center}
\end{table}

\clearpage

\section{Introduction}

% Part 1 and 2 written by Joseph Klimos
% Part 3 and 4 written by Yu-Shang (Daniel) Lin
	
\parindent 
This is a Design document that includes an Architectural Design and diagram. \\

\parindent
It also includes explanation about how the system is broken down and how it interacts with other modules. \\
	
\parindent
This document also covers details about the subsystem interface, followed by a Detailed Design and Diagram, and some Dynamic Scenarios.\\

\parindent 
This document is here to show multiples views of the system, such that it can be easily understood by anybody at any time.



\section{Architectural Design} \label{sec:arch}

% This section must give a high-level description of the system in terms of its modules
% and their respective purpose and exact interfaces.

The systen includes:
- 2 interfaces:	
- User management Panel		\newline	\hspace*{63.5mm}
- Task management Panel			


\vspace*{0.1in}
User management Panel: 	
- Names of the Users		\newline	\hspace*{45.5mm}
- IDs of the Users				


\vspace*{0.1in}
Task Management Panel:	
- Table's IDs						\hspace*{2mm}	The Java pages: - Task.java			
\newline	\hspace*{46mm}
- Title							\hspace*{44.5mm}	- Taskman.java (main)	
\newline	\hspace*{46mm}
- Description						\hspace*{32.5mm}	- TaskFileInput.java (main)
\newline	\hspace*{46mm}
- Duration						\hspace*{37mm}	- TaskFileInputDriver.java	
\newline	\hspace*{46mm}
- Deliverable						\hspace*{33mm}	- FileInput.java	
\newline	\hspace*{46mm}
- Deadline						\hspace*{37.5mm}	- User.java	
\newline	\hspace*{46mm}
- Persons' IDs					\hspace*{31mm}	- Constants.java

		
\vspace*{0.15in}
The information taken for the two interfaces are from an xml file and an input file known as input.txt.

The interfaces interact with the java pages and the input.txt files, to control what small part of the information, so that it is specific and it makes the interfaces different from each others and let the users get exactly what they want.


\subsection{Architectural Diagram}

% A UML class diagram or package diagram depicting the high-level structure of the system,
% accompanied by a one-paragraph text describing the rationale of this design.
% It is mandatory that the system be divided into at least two subsystems,
% and that the purpose of each of these subsystems be exposed here.


\begin {center}
\includegraphics[width=15cm, height=12cm]{UML2Part2.png}     % angle=90 and scale=2  are examples of graphic option

\end{center}

The rational things about the design, is that you can see that the two interfaces do not yet take the real information from the input.txt,
the xml's information and the input.txt are not linked together and do not share the same information.

\vspace*{0.15in}
Another rational thing about the system is that, the two interfaces do no interact together. They may never have too, yet, they may. Still has to be determined later in the process.


\subsection{Subsystem Interface Specifications}

% Specification of the software interfaces between the subsystems,
% i.e. specific messages (or function calls) that are exchanged by the subsystems.
% These are also often called ``Module Interface Specifications''.
% Description of the parameters to be passed into these function calls in order to have a service fulfilled,
% including valid and invalid ranges of values.
% Each subsystem interface must be presented in a separate subsection.


All of it, as shown in the design beforehand, can be divided in 2 subsystems: \\

\parindent
First subsystems includes, the USER Interface, the XML file, the java page known as Taskmanfileinput.java, and the input file known as input.txt.	\\

The User Interface uses the XML file to get the format of its tables and which module (id, Name), it wants from the input file input.txt . to do so, the java page TaskmanFileInput.java, that is used as the event handler, takes that request from the XML file of the User Interface and makes a request of his own to the modules of input.txt file, to be able to get the information needed to fill up the User Interface's Table. \\

Second subsystem includes, the Task Interface, the XML file, the java page know as Taskmanfileinput.java, and the input file known as input.txt.	\\

The Task Interface uses the XML file to get the format of its tables and which module (Title, Description, Duration, Deliverable, Deadline, Person's id), it wants from the input file input.txt . To do so, the java page TaskmanFileInput.java, that is uses as the event handler, takes that request from the XML file of the Task Interface and makes a request of his own to the modules of input.txt file, to be able to get the information needed to fill up the User Interface's Table. \\

\section{Detailed Design} \label{sec:detail}

The purpose of this system is to read a text file containing tasks and process it. it will read the task id, the title
of the task, a detailed description of what to do, the duration of the task, what needs to be handed in, the deadline and
the person this task is to be done by. This system will register all the information into a list for a others to access.

\subsection{Subsystem X}
\subsubsection{Detailed Design Diagram}
\includegraphics[scale=0.5]{soen1}

The first subsystem has three components. The first section is the Taskman.java. This program's function is to take in which
text file to read and process. It also check to make sure that the file exist and will return an error message if the file
is no present. The second section is the FileInput.java. This program's function is to process the text file. It will read each
line in the text file and put it in a list in the system. The last section is the Task.java. This program is the object that
will take in the information of a task. It also has some get and set function so individual variable can be modified.

This design was chosen because it is easy for any programmer to read and it is secure. The system is divided into 3 part so
so that each section will have individual task to accomplish. By putting all the function into a single program would have
been too cluttered and would have had too much information all at once. By separating certain functionality into different
programs, it becomes easier to read. Another reason for separating the functions is to add security. Since Taskman.java called
to find the text file and send it to be processed, many people would use it to process many different files. Since FileInput.java
is the program that will process all the data, only certain people would be allowed to work on it. By separating Taskman.java
and FileInput.java, we can set different permissions so that only certain individuals can work with FileInput.java. Finally,
Task.Java is an object class that is used to store individual task. It is conventional to put in into its own section.

\subsubsection{Units Description}

Taskman.java:
	Program takes in the text file to be processed. If no text file name is given, the default text file to process is called
	input.txt
	
FileInput.java:
	Processes the text file and put it into an array list
	
	resetVars: Function initialises all the variables
	loadFromFile: Function reads each line of the text file and place it into the apropiate variable
	export: Function adds the task into the array list
		
Task.java:
	Object class that hold all the information
	
	getId/setId: get/set id
	getTitle/setTitle: get/set title
	getDescripption/setDescription: get/set Description
	getDuration/setDuration: get/set Duration
	getDeliverable/setDeliverable: get/set Deliverable
	getDeadline/setDeadline: get/set Deadline
	getPersonId/setPersonId: get/set the person tasked for this job
	toString: output the task, the description and the person responsible for this task

\section{Dynamic Design Scenarios}

% Describe some (at least two) important execution scenarios of the system using UML sequence diagrams.
% These scenarios must demonstrate how the various subsystems and units are interacting to achieve a system-level service.
% Units and subsystems depicted here must be compatible with the descriptions provided in
% section \ref{sec:arch} and \ref{sec:detail}.

\includegraphics[scale=0.8]{soen3}

Scenario 1:
File is sent to Taskman.java for processing. It reads the file, sends the information to FileInput.java to process.
FileInput reads each lines and place the information in a placeholder variable. After all the information for a task is read,
It place all the information in a task object which then places it in a list. The loop continues until the end of the file.


\includegraphics[scale=0.8]{soen4}

Scenario 2:
User uses TasksManagementWindow.Java to check up on all the information of a task using the task ID

\end{document}
